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INTRODUCTION 

There has been a considerable investment of 
resources by both government and industry in the 
development of automated structural design and analy- 
sis methods (e.g., refs. 1 and 2). In addition, a 
number of interdisciplinary design studies have been 
completed which indicate the benefits of these methods 
in design (e.g., ref. 3). Computer implementations of 
such methods for use in design studies typically take 
the general form given in figure 1. As the figure 
shows, each discipline begins its own intradiscipli- 
nary analysis and optimization with an initial 
design. However, one discipline (e.g., flutter 
sizing) may be dependent upon results found in the 
analysis and optimization process of another disci- 
pline (e.g., strength sizing). Thus, once the 
strength sizing has been completed, the results are 
used to set a minimum gauge in place of estimates pre- 
viously .input for the flutter sizing. This is a 
sequential approach to automated design and implies 
that iterations are to be made until an optimum design 
is obtained. However, because of budget and time con- 
straints, very few (if any) iterations with interdis- 
ciplinary optimization are carried out in design study 
applications. Wh'H is needed, therefore, is an 
approach which allows concurrent multidisciplinary 
analysis and optimization (fig. 2). In such an 
approach, the software system is capable of performing 
the analysis for several disciplines in parallel 
(concurrent analysis) and then have the optimizer take 
into account the constraints from all the different 
analyses (concurrent optimization), allowing users to 
achieve more iterations and therefore obtain a more 
optimal design than of that from the sequential 
approach. One of the long-term goals at NASA's 
Langley Research Center (LaRC) is to develop the meth- 
odology for such systems. 

As a part of the effort to reach this long-term 
goal, LaRC has been combining analysis and optmization 
codes since 1971. The resulting programs show a 
steady evolution from relatively elementary, special- 
purpose programs with limited capabilities to modular, 
flexible systems of programs with more general capa- 
bilities. This paper first traces the three evolu- 
tionary lines along which computer programs combining 
analysis and optimization have beendeveloped at LaRC, 
namely, strength sizing, concurrent strength and flut- 
ter sizing, and general optimization (fig. 3). Analy- 
tical and computational advances contributing to this 
evolutionary process are described. The near-term 
goal, a state-of-the-art software system which exe- 
cutes the analysis and optimization in a sequential 
rather than concurrent mode, is then described as a 
major step toward reaching the long-term goal. 

Finally, one of LaRC's current efforts in combining 
analysis and optimization codes to be incorporated 
into the software system satisfying the near-term goal 
is described. The description of this current effort 
is in terms of how this analysis and optimization 
system works, how this system is connected using a 


special-purpose language, how this system communicates 
with a data base, and how new programs can easily be 
added to the system. Some numerical results are also 
shown. 


PAST COMBINATIONS OF ANALYSIS AND OPTIMIZATION AT 
LANGLEY RESEARCH CENTER 


Beginning in 1971, there has been a steady pro- 
gression of programs or systems of programs combining 
analysis and optimization which were developed either 
in-house at LaRC or under contract. This progression 
of programs is listed below along with the meaning of 
their names (where applicable), the primary date of 
publication, and reference(s) : 


1971 DAWNS (Design of Aircraft WiNg Structures, ref. 

1971 SWIFT (refs. 5 and 6) 

1972 SAVES (Sizing Aerospace VEhicle Structures, 
ref. 7) 

1972 FADES (Fuselage Analysis and DEsign of Struc- 
tures, refs. 8 and 9) 

1973 WIDOWAC (Wing Design Optimization With Aero- 
elastic Constraints, ref. 10) 

1978 ISSYS (Integrated Synergistic SYStem, ref. 11) 

1979 PARS (ProgrAm for Resizing Structures, ref. 12) 
1979 PROSSS (PROgraming Structural Synthesis System, 

refs. 13 and 14) 

1981 Distributed PROSSS (refs'. 15 and 16) 


rrugrdms como.imng analysis and optimization at 
LaRC have evolved along the three lines indicated in 
figure 3. These lines are: (1) strength sizing, ( 2 ) 

concurrent strength and flutter sizing, and (3) gen- 
eral optimization. The evolution of programs along 
each of these lines was a natural consequence of 
advances in six areas: (1) structuraV appl ication 

(components), (2) structural representation (mathemat- 
ical model), (3) analysis, (4) optimization, (5) flex- 
ibility of use, and (6) computer implementation fea- 
tures. The effect of these advancements on the evolu- 
tionary process is described briefly .below. A more 
detailed comparison of these six areas is given in 
Tables 1-3. 

strength sizing is the first line of evolution. 
The first codes in this line, DAWNS and FADES, were 
very limited in the size of the models they could 
analyze because all of the analysis and data handling 
was executed in core. The control of their execution 
was done through main programs and subroutines, or 
overlays. For optimization, DAWNS used the weight/ 
coupled With fully-stressed design 
(FSD). Techniques allowing the use of mathematical 
programing to solve optimization problems were incor-' 
c?wrr “ P''° 9 rams beginning with FADES. 

SAVES was the first system to use a general-purpose 
finite-element program (NASTRAN, ref. 17) for analy- 
sis. The use of NASTRAN allowed much larger problems 
to be solved in a batch environment because not all of 
the data had to be kept in core. The data handling 
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was done using sequential data files stored on disk 
during execution and magnetic tapes for restarting. 
SAVES was controlled by a FORTRAN callable subroutine 
which called sequences of control cards to execute 
various programs. Although SAVES was capable of 
analyzing a complete airframe, the optimization pro- 
cess was adapted from DAWNS and limited to wing struc- 
tures. 

When SPAR (ref. 18) was developed, the user was 
provided with a finite element analysis program suit- 
able for an interactive environment because of its 
modularity, but still applicable to large models. At 
about the same time, the Control Data Corporation 
(CDC) Network Operating System (NOS)l became avail- 
able at LaRC. With NOS, the user was able to take 
advantage of permanent disk files, interactive opera- 
tion, and a method of combining CDC executive control 
language commands (ref. 19) into procedure files. 

ISSYS then evolved to take advantage of the features 
offered by SPAR and NOS. Most of the data handling 
and storage is done using the SPAR data management 
system (DMS). The controlling network accessed proce- 
dure files using CDC executive command control lan- 
guage to connect more than one program into a modular 
system. ISSYS, using SPAR and the method of usable- 
feasible directions, could perform structural analysis 
and optimization on a complete airframe. The modular- 
ity of ISSYS allowed programs to be added which per- 
formed aerodynamic and aeroelastic analysis. However, 
in ISSYS, the structural and flutter optimizations 
were executed sequentially rather than concurrently. 

Concurrent strength and flutter sizing is the 
second line of evolution. SWIFT and WIDOWAC, like 
DAWNS and FADES, were very limited in the size of the 
models they could analyze because all of the analysis 
and data handling was .done in core. Both programs 
used the sequential unconstrained minimization tech- 
nique (SUMT, ref. 20) for optimization. SWIFT suc- 
ceeded in performing concurrent strength and flutter 
sizing, but only for simple plate wings. WIDOWAC 
evolved from SWIFT to take advantage of the finite- 
element method (FEM) for structural representation. 
PARS was developed to take advantage of the features 
in SPAR. For example, PARS used the SPAR special- 
purpose language (runstreams) to control the flow of 
execution. Programs were added to SPAR to perform 
optimization, and aerodynamic and aeroelastic analysis 
making PARS a modular system within a single program. 
These programs, when incorporated into SPAR, are 
called SPAR processors. PARS became the first system 
to allow the user to perform strength and flutter 
sizing on a general structure. Although WIDOWAC and 
PARS were both originally designed to perform con- 
current strength and flutter sizing, upon implementa- 
tion it was found that this was not economically feas- 
ible within the state-of-the-art of analysis as it 
then existed. Thus, both WIDOWAC and PARS were reset 
to execute in a sequential mode. Additional work is 
required to obtain approximation techniques that would 
reduce the cost of such analyses to some economically 
feasible level (refs. 21, 22). 

General optimization is the third line of evolu- 
tion. CONMIN (ref. 23) is a general-purpose optimizer 
based on the method of usable-feasible directions and 
gives the user a optimizer that can easily be inter- 
faced with analysis codes. The Approximation Concepts 
Code for Efficient Structural Synthesis (ACCESS, 
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ref. 24) provided a methodology for using reciprocal 
design variables, design variable linking, and linear 
approximations. PROSSS was developed to take advan- 
tage of the features in SPAR, CONMIN, NOS, and some of 
the methodology provided by ACCESS. It should be 
noted that before PROSSS all of the analysis/optimiza- 
tion codes at LaRC relied on a preset definition of 
the design variables, constraints, and objective func- 
tion, as well as a preset optimization procedure. 

With PROSSS, the user gained a large degree of flexi- 
bility because of the way in which the programs within 
the system pass data and are connected by executive 
control language commands. This connecting network 
allows the user to substitute problem dependent pro- 
grams and formulations of the design variables, con- 
straints, and the objective function at execution time 
thus making the system adaptable to a wide spectrum of 
structural optimization problems. Although SPAR and 
CONMIN are used for the analysis and optimization in 
PROSSS, other analysis and/or optimization programs 
could be substituted. Distributed PROSSS evolved from 
PROSSS after a PRIME minicomputer was made available 
to LaRC researchers. Distributed PROSSS takes advan- 
tage of the best features of both the mainframe (e.g., 
faster CPU) and the minicomputer (e.g., virtual 
storage and faster interaction) by distributing the 
structural analysis and optimization process between 
the two computers. Distributed PROSSS also reduced 
the complexity of the system by placing a majority of 
the control (previously handled through executive 
command control language) within a FORTRAN program on 
the minicomputer. The ability to examine and plot 
intermediate results from Distributed PROSSS signifi- 
cantly reduced the total amount of wall-clock time 
required for the design process. 

As the above synopsis indicates, during the 
period 1971-1981 there has been a steady progressive 
development of computer programs combining analysis 
and optimization at LaRC toward the long-term goal of 
developing the methodology to perform concurrent 
analysis with concurrent optimization. This long-term 
goal requires that the software system have the capa- 
bility of performing the analysis for several disci- 
plines in parallel (concurrent analysis) and then have 
the optimizer take into account the constraints from 
all the different analyses (concurrent optimization). 
One way this can be accomplished is to combine the 
methodolo^ from Distributed PROSSS with a multilevel 
optimization system for decomposing a large optimiza- 
tion problem into a hierarchy of much smaller problems 
(ref. 25). Engineers can then work the smaller pro- 
blems using a distributed network of state-of-the-art 
micro- and minicomputers connected to a common data 
base. The development of analysis/optimization pro- 
grams is continuing and a near-term goal has been 
established. The near-tenm goal for combining analy- 
sis and optimization will execute in a sequential 
rather than concurrent mode. Hence, the near-term 
goal does not meet the the requirements of the long- 
term goal, but it is a major step in that dirction. 

This near-term goal is discussed in the next section. 

THE NEAR-TERM GOAL FOR COMBINING ANALYSIS AND 
OPTIMIZATION AT LARC 

As presently defined, the near-term goal for 
combining analysis and optimization codes at LaRC is 
to develop a modular software system which combines 
general-purpose, state-of-the-art, production-level 
analysis computer programs for structures, aerody- 
namics, and aeroelasticity with a state-of-the-art 
optimization program featuring an FSD capability as 
well as either the method of usable-feasible direc- 
tions or SUMT. This system is to be applied to gene- 
ral structures using (1) finite element models. (2) 


2 


general, user-defined design variables, constraints, 
and objective function, (3) a user-formulated optimi- 
zation procedure, and (4) a DMS for storing and 
retrieving data. PARS, ISSYS, PROSSS, and Distributed 
PROSSS do not satisfy all of these criteria. For 
example, PARS and ISSYS only allow a preset definition 
of design variables, constraints, objective function 
and optimization procedure. In addition, ISSYS Is not 
applicable to a general structure. PROSSS and Distri- 
buted PROSSS lack aerodynamic and aeroelastic analysis 
capabilities. However, the modularity of PARS, ISSYS, 
and PROSSS and the availability of a new finite 
element analysis computer program called Engineering 
Analysis Language (EAL, ref. 26) have provided the 
necessary Ingredients to develop a software system 
which satisfies all of the above criteria. Because of 
their modularity, each program can be incorporated as 
a processor within EAL. By incorporating each program 
into a single program, the system temporarily loses 
some of the benefits derived from Distributed 
PROSSS. However, it is anticipated that these bene- 
fits will be recovered in the long-term as advances 
are made in distributing hardware and software. 

EAL, which evolved from SPAR, provides the 
required finite element structural analysis capability 
for general structures as well as the DMS. CONMIN, 
which Is contained in PROSSS, satisfies the require- 
ments for an optimization program. The modularity of 
EAL and the capability to add new programs provide the 
user with much flexibility in defining the design 
variables, the constraints, and the objective function 
as well as in formulating an optimization procedure. 
There are efforts currently underway to incorporate 
procedures, processors, and programs from PARS, ISSYS, 
and PROSSS Into EAL. Additional analysis modules 
which are closely related to structural optimization 
(such as new, advanced aerodynamic analyses needed for 
aerodynamic loads and aeroelasticity) will be added to 
EAL to meet the' requi rements of multidisciplinary 
analysis and optimization which deal with the airframe 
directly. The resulting system will be designated 
EAL/ISSYS (fig. 3) and will satisfy the requirements 
set down for the software system meeting the near-term 
goal. Users of this system will have much greater 
flexibility to solve a wide variety of engineering 
problems as well as evaluate new techniques in both 
analysis and optimization. All modules will communi- 
cate through the EAL DMS. Because all of the software 
will be either computer-independent FORTRAN or EAL 
runstreams, this system should be easily portable to 
any other government agency or any private company. 

It is anticipated that In addition to EAL/ISSYS, 
which will be focused on airframes, there will be a 
need for a system supporting much broader applications 
such as general aerospace vehicles. In these applica- 
tions, there will be many other major analyses 
Involved, each represented by a program or system of 
programs too large and too complex to be added as 
processors in EAL. Integration of these programs with 
EAL/ISSYS can be accomplished with the aid of a 
state-of-the-art DMS such as RIM (Relational 
Information Management, ref. 27). A proposed system 
is diagramed in figure 4. In this system, each major 
analysis program has its own data base for storing 
data used only by that program. RIM is used to store 
data (such as design variables and constraints) that 
Is to be passed between the major analysis program and 
procedure files for controlling the flow of execution. 

One of the current efforts at LaRC that will aid 
in reaching the near-term goal (EAL/ISSYS) is the 
incorporation of PROSSS Into EAL to form EAL/PROSSS 
(fig. 3). The remainder of this paper describes the 
salient features of PROSSS and the process for incor- 
porating PROSSS into EAL. Since this process is 
representative of the manner In which any code can be 


incorporated into EAL, the reader should gain some 
understanding as to how EAL/ISSYS is being developed. 

STRUCTURAL ANALYSIS AND OPTIMIZATION USING PROSSS 

The flowchart of the PROSSS structural optimiza- 
tion software system Is shown In figure 5. This flow- 
chart is the same regardless of which of the three 
versions of PROSSS Is being used. The five major com- 
ponents In the system are: (1) initialization; (2) 

analysis (EAL or SPAR); (3) optimization (CONMIN); (4) 
Interface processing; and (5) termination. 

During Initialization, certain problem-dependent 
variables, files, and sometimes file names are Ini- 
tialized to the desired values. An example of this is 
the input data required for CONMIN. The initializa- 
tion is not repeated during the analysis/optimization 
process. 

There are two parts to the analysis portion of 
the process. One part, the nonrepeatable analysis. Is 
executed outside of the optimization loop and Is 
executed only once unless the user changes the struc- 
tural model. The nonrepeatable part of PROSSS gene- 
rates tables of material constants, section proper- 
ties, joint locations, and element connectivities for 
the initial design variables. If analytical gradients 
are required, then the derivatives of the mass and 
stiffness matrices with respect to each design vari- 
able are also computed. These data are then stored In 
the data base on a temporary disk file and are 
referenced by other programs in the optimization 
loop. These data can also be saved on a permanent 
file so that it is not necessary to execute the 
nonrepeatable analysis for each subsequent execution 
of PROSSS. This is a very desirable feature when the 
user has a fixed model and is evaluating various new 
optimization and analysis techniques. The second part 
of the analysis portion of the process is the 
nonrepeatable analysis which Is executed iteratively 
In the optimization loop. During this portion of the 
analysis, the changed design variables are used to 
calculate the new behavior variables for the 
structure. If analytical gradients are required, th 
the derivatives of the behavior variables are also 
computed. These data are also stored In the data 
base. 

CONMIN, the optimizer, computes a new set of 
design variables based on the values of the objective 
function, constraints, and optionally their 
gradients. In PROSSS, CONMIN is treated as a “black 
box". A user-supplied, problem-dependent driver pro- 
gram Is written to Input the data created by the end 
processor, call the optimization subroutines, and out- 
put data using either files or the data base, depend- 
ing upon the version of PROSSS being used. 

The interface processors are also user-supplied, 
problem-dependent programs. They are used to communi- 
cate between the analysis and optimization programs. 

The front processor receives the updated design vari- 
ables from CONMIN and converts the data into a format 
suitable for input Into SPAR or EAL. The end pro- 
cessor receives the behavior variables, and optionally 
their derivatives for analytical gradient calculation, 
and converts the data into constraint data formatted 
for input into CONMIN. The capability of adding these 
two processors and the CONMIN driver program to EAL 
contributes to the flexibility of the system. 

Certain termination criteria (such as the objec- 
tive function not changing greater than a given tole- 
rance within three successive passes through the 
system) are determined within the CONMIN driver pro- 
gram. If these criteria are met, the CONMIN driver 
program creates a termination file causing execution 
to terminate. Execution mdy also terminate if a pre- 
defined number of optimization loops is exceeded. The 
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last criterion prevents the user from spending too 
much computer time on a poorly defined problem. 

INCORPORATION OF PROSSS INTO EAL 

Incorporating PROSSS into EAL to form EAL/PROSSS 
is one of LaRC's current efforts in the evolutionary 
process of combining analysis and optimization codes. 

A system with enhanced portability and flexibility is 
achieved by taking advantage of the EAL special- 
purpose language commands and data base. Use of the 
EAL data base simplifies the restarting of an abnor- 
mally terminated EAL execution. The ease in which new 
processors can be added to EAL makes the system 
readily adaptable to a wide spectrum of structural 
optimization problems. The remainder of this paper 
describes these features in detail. In addition, the 
model used for validating each of the PROSSS systems 
is described and the key results are shown. 

Connecting Processors in EAL with the EAL Special- 
Purpose LaTTguaYe 

The connecting network ties all of the system's 
components together. For PROSSS, an executive control 
language network connects procedures, programs, and 
data. For Distributed PROSSS, FORTRAN programs using 
a PRIME feature of FORTRAN callable procedure files 
replaced the complex procedure files used in PROSSS. 
The procedure files in Distributed PROSSS are very 
simple, because the FORTRAN driver programs contain 
all the looping, branching and testing logic required 
for executing the programs in PROSSS. 

EAL (Engineering Analysis Language) is, as the 
name implies, a special purpose language contained 
within a state-of-the-art finite element computer pro- 
gram. This language gives the capability of doing 
most of the operations normally done in FORTRAN. The 
operations include testing, branching, looping and 
arithmetic calculations. "There are also commands that 
simplify retrieval of data from the data base. The 
commands are simple and easy to use. For example, to 
branch in EAL requires: 

♦JUMP 100 


♦LABEL 100 

Thus, the controlling network can now be written in 
computer-independent EAL runstreams. 

In the two earlier versions of PROSSS, SPAR was 
used for the analysis and two FORTRAN programs were 
written to create SPAR runstreams to aid in calcu- 
lating analytical graidents. FORTRAN programs were 
used because the runstreams had to be general and 
satisfy any number of load cases and any number and 
type of design variables. SPAR, although quite simi- 
lar to EAL in many respects, lacks the EAL commands 
for looping, testing, and branching. Thus, another 
advantage to incorporating PROSSS into EAL is that the 
two FORTRAN programs can be replaced by two general 
EAL runstreams that take advantage of EAL's looping 
and branching commands. This increases portability 
while decreasing complexity. A portion of the listing 
containing the EAL runstream for computing the deriva- 
tives of the stiffness and mass matrices with respect 
to the design variables is shown in table 4 as an 
example of the commands used in EAL. 

Communicating Between New Processors and the EAL Data 
Base 

Incorporating PROSSS into EAL takes advantage of 
the EAL data base. The data base is written so that 
it can easily be accessed by any processor using 
FORTRAN callable utility subroutines. These utility 
subroutines are stored in the main overlay which 


remains in core at all times; thus these subroutines 
are available not only for the original EAL pro- 
cessors, but also for any processors the user may wish 
to add. 

To use these subroutines, the user must be fami- 
liar with their functions and calling parameters 
(ref. 28) as well as how the data are stored in the 
data base (ref. 29). Data are stored in the data base 
in two-dimensional tables or matrices called data 
sets. The data sets are referenced by a four-word 
name such as STRS E23 i j — where STRS means stress, 

E23 is the element type, i is the load set number, 
and j is the load case number within the load set. 
The data sets are stored on disk in libraries within 
the data base (fig. 6). When two data sets containing 
data for the same item and having the same data set 
name exist on the same library in the data base, only 
the latest stored item can be accessed by other pro- 
grams. There are 30 libraries available for the user 
to store data sets, however, library 30 is generally 
reserved for system usage. Data sets can be trans- 
ferred from one library to another using standard EAL 
runstream commands. The typical user only stores data 
in library 1, which is the default. 

One of the powerful features of EAL is the capa- 
bility of extracting data from the data base using 
runstream commands. This information is very useful 
in setting up general-purpose runstreams. Using this 
capability such information as the number of design 
variables, number of load cases, number of joints, and 
element names can be extracted from the data base and 
stored in runstream variables called registers. These 
registers are then used for loops, branches and calls 
to other data sets within the general runstream. This 
means that some runstreams, such as the runstream that 
computes the derivatives of the stiffness and mass 
matrices with respect to the design variables, do not 
have to be coded differently for different problems or 
different users. 

It may also be necessary for users to create 
their own data sets for use in the processors they are 
coding. The user is then responsible for the naming 
of the data set and the format in which the data is 
stored within the data set. An example of this type 
of data set in EAL/PROSSS .is the data set containing 
the design variables. These data sets are not used by 
the standard EAL processors, but are used to pass data 
between the front and end processors, and the CONMIN 
driver, all of which are coded by the user. 

The ability to communicate between a processor in 
central memory and the data base on disk requires that 
certain EAL utility subroutines be used. The data 
being used in EAL processors are usually stored in the 
central memory area reserved for blank common (fig. 

6). These routines are used for moving data from 
blank common into the data base and moving data from 
the data base into blank common. The call to the 
utility subroutine first specifies the data set which 
is to be addressed within the library. A starting 
address in central memory is also passed in the 
subroutine call. The starting address, usually an 
address within blank common, specifies the address in 
central memory where the data being retrieved from the 
data base is to be placed or an address in central 
memory that is to be stored in the data base. An 
operation code, also passed through the subroutine 
call, specifies whether the data areto be stored or 
retrieved. Once the data have been placed in the data 
base, it can be accessed by any other processor or 
runstream. Once the data have been successfully 
transferred from the data base to central memory, it 
can be used in the accessing processor just as any 
data might be used. 

In the two earlier versions of PROSSS, only data 
created by the SPAR analysis was stored in the data 
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base. Data for initialization and data created by the 
front and end processors and CONMIN were all kept on 
separate disk files. Managing all of these files as 
well as the flow of the system is very cumbersome in 
an executive control language. Because all of the 
data are stored in the EAL data base in EAL/PROSSS, 
the use of files is minimized which greatly reduces 
the complexity of the connecting network. 

Restarting an execution in EAL is simple because 
of the data base. A disk file (or files) with 
libraries containing the most recently computed data 
sets is saved at the end of an EAL execution. This is 
true even if the execution terminated abnormally. If 
the execution does terminate abnormally, changes can 
be made either to a processor or to a runstream; then 
the execution can be restarted at the beginning of the 
last pass through the optimization loop. 

A capability that allows the user to examine 
intermediate results is currently available in Distri- 
buted PROSSS and is to be added to EAL/PROSSS. With 
this feature the user will be able to examine plots 
and/or listings of the intermediate results and 
determine if the analysis/optimization process is 
executing as anticipated. If a problem is discovered, 
the user can stop the execution, make the necessary 
changes, and then restart execution. For example, the 
user, upon examining his intermediate results, may 
find that one of the design variables is lodged 
against a lower-bound constraint which was input to 
CONMIN. At this point, the user can stop execution, 
relax the constraint condition, and then restart exe- 
cution. Because of this restart feature, loss of 
previous (and sometimes expensive) calculations can be 
prevented. 

Adding Processors* to EAL 

Just as ftjRTRAN programs call subroutines to per- 
form a specific task, EAL calls processors. The pro- 
cessors are incorporated into EAL as overlays. The 
main overlay, which is always in core, contains the 
input/output routines and commonly used utility pro- 
grams. The next (primary) level of overlay contains 
the processors. The main overlay can call a primary 
overlay into core (fig. 6). In EAL, this is done with 
runstream commands such as: 

*XQT processor name 

To add PROSSS to EAL requires the addition of new 
processors external to EAL, such as the front pro- 
cessor, the end processor and the CONMIN driver. 

Since EAL is a proprietary program, its source code is 
not available at LaRC. To add a new processor 
requires using an external overlay as shown in figure 
7. When an *XQT command is encountered in EAL, a 
test is made to see if a legitimate EAL processor is 
being called. If it is not a legitimate EAL processor 
and an *XQT EXTERNAL command has already been 
encountered, then EAL branches to an external overlay 
called EXT to execute the additional processors. 

The division of the processors between the two over- 
lays is shown in figure 8. 

The primary overlay in the external overlay con- 
tains a driver program to check and determine if the 
called processor is a legitimate processor in the 
external overlay. If it is not a legitimate pro- 
cessor, an error message is issued. If it is a legi- 
timate processor, a secondary overlay is called to 
execute the processor. 

As mentioned previously, one of the key features 
of PROSSS is its flexibility. To maintain this flexi- 
bility when incorporating PROSSS into EAL, dumny 
drivers were added to the external overlay. The dummy 
driver program performs only one task, the calling of 
a subroutine with a specific name. Thus, once the 


relocatable overlay structured file is created it does 
not have to be recreated for different users or 
different problems. The unsatisfied subroutines 
called by the dumn\y driver programs in the external 
overlay program are satisfied at load time with user- 
supplied, problem-dependent subroutines. The only 
requirement placed on the user is that the subroutine 
names used in the dumny driver programs must also be 
used in the subroutines. The file containing the sub- 
routine can have any name. 

Another key feature available when adding new 
processors to EAL is the use of reset. EAL provides a 
utility routine for resetting certain variables used 
in the processors. This is similar to the passing of 
parameters to subroutines. When a user writes a pro- 
blem-dependent processor, variables can be initialized 
with default values in data statements. Should the 
user decide to change the defaults at execution time, 
there is no need for him to change the source code, 
recompile, and reload the absolute overlay. A reset 
command with the variable name and its new value 
following the command that executes the processor can 
be added. For example, suppose the external processor 
EPRC required the number of beam elements (NE21) used 
in the model as input. Suppose the user initially 
defaults the NE21 parameter to 75, but now wishes to 
change the number of beam elements to 100, then the 
following commands are required: 

*XQT EPRC 

RESET NE21=100 


The EAL utility routine is then called by the pro- 
cessor to reset the variable. The only thing required 
of the user is to plan ahead and design code to handle 
all variables that might be reset. 


lesi case 


. A 337 degree-of -freedom finite element model of 
an idealized segment of a fuselage with a cutout 
(fig. 9) was used to test each version of PROSSS. Tht 
model consists of 80 joints connected to form 76 rod 
elements, 58 beam elements and 56 membrane elements. 
The cross-sectional areas of the rods and beams and 
the thicknesses of the membranes were used as design 
variables. For this test case, all rod areas are 
equal, as are the areas of the beams, and the thick- 
nesses of the membranes. 

final objective function (mass) for EAL/ 
PROSSS was 6343 Kg which agrees with the 6344 Kg found 
with PROSSS. The final cross-sectional area of the 
rods and the thicknesses of the membranes were in 
exact agreement at 2.0390 cm2 and 0.1207 cm, respec- 
tively. There was only a slight difference in the 
final cross-sectional area of the beams between the 
two systems. EAL/PROSSS resulted in a cross-sectional 
area of 1.6025 cm^ while the final area for 


was 1.6002 cm 


PROSSS 


CONCLUDING REMARKS 

The evolutionary process of combining analysis 
and optimization codes at Langley Research Center is 
described with a view toward providing insight into 
the long-term goal of developing the methodology for 
an integrated, multidisciplinary software system for 
the design of aerospace structures. A current effort 
in this evolutionary process is discussed, particular- 
ly as it relates to the near-term goal of combining 
state-of-the-art, general-purpose, production-level 
analysis computer programs with a state-of-the-art 
optimization program. This effort, a software system 
designated EAL/PROSSS, is described in terms of its 
special -purpose language and data base features, and 
the process used for adding new programs. Some 


5 



numerical results showing the accuracy of EAL/PROSSS 
are given. 
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TABLE I.- COMPARISON OF PROGRAMS WITH RESPECT TO STRUCTURAL APPLICATION AND REPRESENTATION 




71 

DAWNS 

71 

SWIFT 

72 

SAVES 

72 

FADES 

73 

WIDOWAC 

78 

ISSYS 

79 

PARS 

79 

PROSSS 

81 

DIST. PROSSS 


WINGS 

X 

X 

X 


X 

X 

X 

X 

X 

STRUCTURAL 
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X 

X 
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X 

APPLICATION 
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X 

X 

X 
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X 

X 

X 


STRUCTURAL 

REPRESENTATION 

FINITE ELEMENT 
MODEL (DISCRETE) 

X 


X 

X 

X 

X 

X 

X 

X 

PLATE 

(CONTINUOUS) 
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TABLE II.- COMPARISON OF PROGRAMS WITH RESPECT TO ANALYSIS AND OPTIMIZATION 




71 

DAWNS 

71 

SWIFT 

72 

SAVES 

72 

FADES 

73 

WIDOWAC 

78 

ISSYS 

79 

PARS 

79 

PROSSS 

81 

DIST. PROSSS 


STRUCTURAL 

(STATICI 

X 

X 

X 

X 

X 

X 

X 

X 

X 


STRUCTURAL 

(DYNAMIC) 


X 

X 


X 

X 

X 

X 

X 

ANALYSIS 

AERODYNAMIC 

X 

X 

X 


X 

X 

X 




AEROELASTICITY 

(STATIC) 



1 


X 

X 

X 




AEROELASTICITY 

(DYNAMIC) 





X 

X 
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OPTIMIZATION 

WEIGHT/STRENGTH 

X 
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USABLE- FEASIBLE 
DIRECTIONS 
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X 

X 

SUMT 
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X 

X 


X 
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X 

X 
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TABLE III.- COMPARISON OF PROGRAMS WITH RESPECT TO FLEXIBILITY AND COMPUTER IMPLEMENTATION FEATURES 
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X 

X 

X 

X 

X 

X 

X 
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X 

■ 

X 


COMPUTER 

IMPLEMENTATION 

FEATURES 
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X 
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X 
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X 

X 
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X 
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X 
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X 
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X 

X 
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TABLE IV,- SAMPLE EAL RUNSTREAM 


♦ XOT AUS 
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r-1 
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I ICNT-0 
S 

% COMPUTE OBJECTIVE FUNCTIONS 

$ 
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I ICNT-0 

ITOLC-LCOS-1 

QUTLIB-3 


LIMITED INTERDISCIPLINARY OPTIMIZATION 



DISCIPLINES: AERODYNAMICS STRUCTURES AEROELASTICITY 


STRENGTH SIZING 

(f^s) 


CONCURRENT STRENGTH 
AND FLUHER SIZING 


GENERAL OPTIMIZATION 



(SW^IFT) 

(WIDQWAC^ 


STRENGTH SIZING 
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FLUTTER SIZING 
ISSYS 
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(/GENERAL PURPOSED 
V OPTIMIZER 


XCCE55 
J METHODOLOGY) y 


Cprosss 


X eal/pros's? 



^“eal/issys'^A 

V^NEAR-TERM GOALy 


►COMPLETED DEVELOPMENT 

- — PLANNED OR UNDER 
DEVELOPMENT 


long-termA ^ 

V GOAL 


(Distributed prosss^ 

DISTRIBUTED^ 

( PROSSS ) 
V METHODOLOGY J 


Fig. 3 Evolutionary lines for combining analysis and 
optimization at LaRC. 



I'lg. 1 A sequential approach to the design process. ^ Proposed multidisciplinary analysis and 

optimization system for general aero- 
space vehicles. 


AERODYNAMIC 

SHAPE 


INITIAL 

DESIGN 


STRENGTH 

SIZING 


FLUHER 

SIZING 


OPTIMIZER 



Fig. 2 A concurrent approach to the design process. 
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Fig. 5 Flowchart of the PROgraming Structural 
Synthesis System (PROSSS). 



















^ ' 

PROCESSORS EXTERNAL TO EAL 


Fig. 6 Data communications in EAL. F’ig* 7 EAL program structure with PROSSS dummy 

driver programs incorporated into an 
external overlay. 



Fig. 8 Divisions of EAL/PROSSS processors between overlays. 
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